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1.0  Summary 


This  Technical  Note  describes  work  performed  to  implement  a  ZKP-based  authentication  protocol  on 
small  stand-alone  processors  suitable  for  use  on  small  UAVs  and  ground  vehicles.  The  objective  of  this 
effort  was  to  transfer  the  ZKP  protocols  from  a  (laboratory)  desktop  operating  environment  to  a 
(deployable)  mobile  wireless  set-up.  The  targeted  systems  consisted  of  commercial-off-the-shelf  (COTS) 
processors  and  wireless  networking  hardware. 

Two  weeks  of  engineering/technician  time  was  allocated  to  perform  the  required  work:  identify 
available  system  hardware  and  LINUX  operating  system  software;  configure  the  standalone  processing 
nodes;  install  the  operating  systems,  software  drivers,  and  necessary  math  libraries;  port  over  the  ZKP 
authentication  protocols;  and  finally,  test  and  demonstrate  protocol  operation  over  wireless 
communication  links.  The  resulting  lessons-learned  will  be  used  in  the  planning  of  future  field 
experiments  involving  (air-to-air  and  air-to-ground)  mobile  wireless  networks. 

The  most  arduous  task  involved  configuring  the  processors'  LINUX  operating  system.  While 
nearly  all  of  the  additional  software  routines  needed  were  available  as  freeware  over  the  internet,  they 
could  not  be  downloaded  directly  to  the  processors  through  AFRL's  network  connections.  Instead,  the 
code  had  to  be  first  downloaded  to  a  CD-ROM  then  transferred  to  the  standalone  processors. 
Unfortunately,  none  of  the  embedded  processors  were  configured  to  support  CD-ROM  drives  i.e.,  size, 
weight  and  power  (SWAP)  requirements  precluded  their  use  on  the  UAV  and  ground  stations.  An 
inordinate  amount  of  time  was  spent  locating  compatible  CD-ROM  drives  and  software  drivers,  installing 
them  on  each  of  the  processors,  and  performing  the  needed  software  upgrades. 

Porting  of  the  ZKP  authentication  code  proved  to  be  straightforward.  Only  minor  changes  to  the 
code  were  required:  changing  device  IP  addresses,  and  modification  of  certain  lines  of  code  used  for  the 
set-up  of  communication  sockets.  In  addition,  certain  math  libraries  were  needed  to  compile  the  code. 
Once  again  the  issue  of  downloading  code  from  the  internet  to  the  embedded  processors  had  to  be 
addressed. 

Testing  of  the  ZKP  protocol,  between  various  pairs  of  standalone  processors,  was  not  without 
problems.  While  the  wireless  networks  that  were  implemented  allowed  for  communications  between 
nodes,  successful  operation  the  ZKP  authentication  code  was  achieved  on  only  one  pair  of  like  devices 
i.e.,  a  set  of  ground  stations.  Details  regarding  ZKP  protocol  implementation,  testing  results,  and 
recommendations  for  follow-on  work  are  documented  in  the  remainder  of  this  document. 
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2.0  Introduction 


Authentication  is  required  for  secure  interactions  in  tactical  wireless  mobile  networks.  However, 
implementing  authentication  protocols  in  self-configuring  networks  can  be  problematic  given  that  many 
of  today's  currently  deployed  protocols  make  use  of  centralized  security  policies  and  controlled  security 
infrastructure  i.e.,  public-key  encryption  mechanisms  and  hardware  to  prevent  unauthorized  access, 
which  demands  that  there  exist  some  degree  of  pre-defined  network  structure  which  would,  in  effect, 
be  counterproductive  with  regard  to  creating  an  ad  hoc  network. 

A  simple  tactical  ad  hoc  networking  scenario  is  illustrated  in  Figure  1.  Here,  an  UAV  is  shown 
entering  a  battlespace  where  it  must  a)  establish  a  network  connection  with  airborne  network  assets 
already  in  theater,  and  b)  make  its  presence  known  to  ground  (network)  users  so  that  they  can  establish 
network  connections  in  order  to  access  on-board  sensor  resources.  Here  we  assume  that  any  node 
entering  a  network  has  no  a  prior  knowledge  of  the  existing  network  topology  and  has  the  added 
responsibility  of  discovering  which  nodes  it  can  securely  communicate  with.  Furthermore,  it  is  assumed 
that  in  the  network  not  all  nodes  are  able  to  directly  communicate  with  each  other,  in  which  case 
information  may  need  to  be  relayed  across  the  network  [1],  In  both  situations,  the  amount  of  time 
available  for  establishing  a  trusted  communication  maybe  limited.  Therefore  it  is  important  that  the 
initiation  of  network  connectivity  and  access  take  no  longer  than  is  absolutely  necessary.  Having 
efficient  security  and  trust  management  schemes  is  critical  to  providing  high-speed  access  to  military 
networks. 


Figure  1:  Typical  air-ground  network  scenario. 
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Authentication  of  user  identity  must  be  a  precondition  to  establishing  secure  communications 
channels  in  a  mobile  ad  hoc  network  (MANET)  [2],  Security  requirements  in  tactical  MANETS  are 
considerably  stricter  than  those  of  civilian  mobile  networks  in  that  users  exist  at  different  levels  of 
authority  and  therefore  require  different  access  rights  and  priorities.  A  main  requirement  for  a 
authentication  scheme  used  in  MANETs  are:  authorized  users  must  get  access  when  required;  the 
protocol  used  must  not  reduce  system  availability;  the  communicating  entities  must  be  able  to  verify  the 
identity  of  the  other  party  at  the  authority  level  required  for  the  type  of  information  exchanged;  and 
unauthorized  users  must  not  gain  access  to  network  resources  and  protected  data  [3],  Use  of  ZKP-based 
authentication  schemes  due  not  rely  on  the  availability  of  a  centralized  management  of  security 
credential  and  therefore  lend  themselves  to  use  in  wireless  mobile  networks. 
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3.0  Methods,  Assumptions,  and  Procedures 


The  authentication  protocol  selected  for  use  in  this  effort  is  based  on  the  Feige-Fiat-Shamir  (FFS)  zero- 
knowledge  proof  (ZKP)  of  identity  scheme  [4],  as  implemented  in  the  C  computer  language  by  Daniele 
Raffo  [5],  and  later  modified  by  Nathanial  Rowe  [6]  for  use  on  an  AFRL  TCP/IP  network.  The  C++  code 
for  the  FFS  ZKP  code  demonstrated  here  is  documented  in  Appendices  A  and  B  of  this  report. 

The  FFS  ZKP  identification  scheme  allows  for  anonymous  authentication  of  identity  through  a 
series  of  transactions  involving  two  entities:  the  Prover,  and  the  Verifier.  The  basic  premise  underlying 
the  scheme  is  that  the  Prover  possess  a  secret  token  and  seeks  authentication  by  the  Verifier,  who  must 
authenticate  the  Prover  based  upon  the  secret  token  that  the  Prover  has,  through  a  series  of  challenges 
without  getting  to  know  the  Prover's  secret  token  [7],  A  simplified  version  of  this  protocol  can  be 
written  [8], [9]  as  follows: 

•  An  arbitrator  (i.e.,  trusted  third  party)  generates  a  random  modulus  n  which  is  the  product  of  two 
large  Blum  primes  integers  p,q  (i.e,  n  =  pq).  The  arbitrator  then  publishes  n  . 

•  Using  n,  the  Prover  creates  a  secret  vector  s  =  [sh  S2,--- ,sk]  with  gcd(Sj,n)  =  1,  and 

c  =  {ci  =  ljk  |  c  e  (0,1)}.  Prover  next  computes  a  public  vector  v  =  [vh  V2,---,vk]  using  v,  where 
=  sf  (mod  n ),  and  publishes  the  result. 

•  The  authentication  protocol  takes  the  form: 

1.  Prover  picks  a  random  integer  r,  a  random  sign  b  e  {-1,1}  and  computes 

x  =  (— l)ci=i,fc  ■  r2  mod  n,  otherwise  referred  to  as  a  witness,  and  sends  it  to  the 
Verifier. 

2.  Verifier  selects  random  Booleans  [a!,..., a,]  where  a,  e  {0,1}.  The  Verifier  then  sends  this 
vector  to  the  Prover  as  a  challenge. 

3.  Prover  computes  y  =  r  (s/31  s2a2  •••  skak )  mod  n  using  its  private  key.  The  Prover  then  sends  the 
result  to  the  Verifier. 

4.  Verifier  computes  z  =  x  (vialv2a2---  vkak )  mod  n  and  confirms  z  =  y2  mod  n.  If  the  relation 
proves  true,  then  proof  of  identity  is  accepted.  Confirmation  of  pass/fail  is  sent  to  the 
Prover. 


The  series  of  transactions  that  make  up  the  protocol  are  diagrammed  in  Figure  2.  Depending  on  the 
level  of  security  required,  the  process  can  be  repeated  a  number  of  times  thereby  decreasing  the 
probability  that  the  Verifier  can  be  fooled  by  a  dishonest  or  malicious  Prover. 
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Prover 


Verifier 


Figure  2:  Typical  single  round  authentication  process. 
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While  wireless  communications  frees  users  from  having  to  deal  with  a  hardwired  infrastructure 
and  fixed  topology  it,  unfortunately,  makes  implementing  security  and  trust  management  more  difficult. 
Mobile  wireless  network  operations  can  be  impacted  as  users  move  in  and  out  of  coverage  range.  As 
the  distance  between  wireless  nodes  increases,  the  signal  to  noise  ratio  decreases  and  the  achievable 
throughput  is  reduced  making  network  operations  somewhat  unpredictable  [10].  This  can  challenge 
network  activities  and  result  in  high  error  rate  and  asymmetric  data  rates,  low  transmission  rates,  large 
latencies,  and  intermittent  connectivity,  as  well  as  disconnection,  and  intermittent  and  unpredictable 
operation  [11],  Additionally,  efficient  authentication  protocol  operation  can  also  be  affected  due  to  the 
unavailability  of  resources.  Deployed  devices  may  have  limited  amounts  of  processing  capability, 
memory,  and  power  availability  which  may  delay,  or  restrict,  the  time  exchange  of  data.  As  a  result,  the 
testing  of  authentication  protocols  need  to  be  carried  out  using  systems  appropriate  to  mobile 
applications  rather  than  on  hard-wired,  laboratory  computer  networks. 

Our  approach  to  testing  involved  porting  existing  ZKP-based  authentication  protocols  (which 
have  been  tested  on  networked  desktop  computers)  to  field-deployable,  battery-operated  wireless 
devices  destined  for  use  in  AFRL's  in-house  small  UAV  research  program.  A  basic  two-node  wireless 
network  was  set-up  in  an  indoor  laboratory  to  allow  for  experimentation  with  various  mobile  device 
configurations  to  demonstrate  operation  of  the  authentication  protocol.  The  block  diagram  provided  in 
Figure  3  illustrates  the  configuration  of  the  test  network.  Results  obtained  from  this  initial  round  of 
testing  would  help  determine  the  course  of  future  outdoor  experiments  involving  mobile  airborne  and 
mobile  ground  nodes. 


Figure  3:  Two  processor  benchtop  wireless  setup. 


Two  different  wireless  computer  systems  were  selected:  a  payload  system  designed  for 
installation  on  a  small  UAV;  and  a  portable  ground  station  used  for  communicating  with  the  airborne 
payload,  but  also  can  be  configured  for  mobile  ground  applications.  The  UAV  payload  electronics 
package  is  shown  in  Figure  4  while  the  ground  station  is  illustrated  in  Figure  5.  Both  the  payload  and 
ground  stations  systems  are  designed  to  operate  off  of  external  (battery)  power  sources  that  are 
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installed  on  either  the  UAV  or  the  mobile  ground  vehicles.  For  benchtop  testing  purposes  commercial 
dc  power  supplies  were  employed.  In  addition,  all  systems  tested  were  outfitted  with  5.5  dBi  rubber 
duck  antennas.  The  rubber  duck  antenna  screws  directly  into  the  existing  external  antenna  port  and 
swivels  360  degrees  as  well  as  tilts  up  to  90  degrees. 

The  UAV  payload  package  consists  of  a  processor  board  (model:  PM-945GSE-270)  and  wireless 
radio  board  (model:  TL-WN861N)  which  are  stacked  and  attached  to  a  convection-cooled  heatsink.  An 
instrumentation  cable  allows  for  external  connections  to  a  monitor,  keyboard  and  network  for 
performing  preflight  tests. 


A)  Electronics 


B)  Payload 


Figure  4:  UAV  payload  processor  device. 
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The  ground  station  is  outfitted  with  a  number  of  devices  which  include  a  processor  board 
(model:  PM-LX2-800-R10)  and  wireless  radio  board  (model:  TL-WN861N)  along  with  an  RF  attenuator,  a 
Cisco®  five  port  10/100  switch,  and  a  Microhard  Systems®  spread  spectrum  modem  (model:  MHX320). 
For  the  tests  described  herein  only  the  processor  and  RF  radio  boards  where  utilized. 


Figure  5:  UAV  ground  station  electronics  package. 

The  PM-945GSE-270  and  PM-LX2-800-R10  are  highly  integrated  embedded  computers 
specifically  optimized  for  multi-media  applications  requiring  minimum  installation  space  [12].  The 
processor  board  is  particularly  suitable  for  low  power  and  fan-less  applications.  Specifications  for  these 
single-board  computers  are  provided  in  Tables  1  and  2.  Both  systems  use  the  same  embedded  radio 
frequency  (RF)  wireless  radio:  model  TL-WN861N.  Specifications  for  the  RF  wireless  board  [13]  are  listed 
in  Table  3. 
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Table  1:  UAV  payload  computer  specifications. 


Specification/Model 

PM-945GSE-N270 

Form  Factor 

PCI-104  Module 

Processor 

Intel®  Atom™  N270  CPU 

Integrated  Graphics 

lntel®945GSE 

On-board  Static  Memory 

1  GByte  DDR2  SDRAM 

System  Controller  Flub  Chipset 

lntel®ICH7M 

BIOS 

AMI  BIOS 

Compatible  OS 

Microsoft®  Windows  XP™  SP2 

Microsoft®  Windows  Vista  Business™  (32bit) 

Linux  Ubuntu™  8.10 

Linux  Fedora™  Core  6 

Ethernet  Controller 

Realtek®  RTL8102E 

Super  I/O  Controller 

Fintek®  F81865 

Dimensions 

108.6  mm  x  115.6  mm 

Weight 

250  g 

Power  consumption 

5  VDC  @  2.6  A 

Table  2:  Ground  station  computer  specifications. 


Specification/Model 

PM-LX2-800-R10 

Form  Factor 

PC- 104  Module 

Processor 

AMD®  Geode™  LX800  CPU 

Integrated  Graphics 

AMD®  LX800 

On-board  Static  Memory 

1GByte  DDR2  SDRAM 

System  Controller  Flub  Chipset 

SMSC3114 

BIOS 

AMI  BIOS 

Compatible  OS 

Microsoft®  Windows  XP™  SP2 

Microsoft®  Windows  Vista  Business™  (32bit) 

Linux  Ubuntu™  8.10 

Linux  Fedora™  Core  6 

Ethernet  Controller 

Realtek®  RTL8100C 

Super  I/O  Controller 

SMSC3114 

Dimensions 

90  mm  x  90  mm 

Weight 

110  g 

Power  consumption 

5  VDC  @  1.09  A 

The  TL-WN861N  wireless  adapter  board  complies  with  IEEE  802. lln,  IEEE  802. llg,  and 
IEEE  802.11b  standards.  Wireless  transmission  rates  are  specified  up  to  300Mbps.  This  device  supports 
64/128/152-bit  WEP,  WPA/WPA2  and  WPA-PSK/WPA2-PSK  encryptions.  This  device  can  also 
simultaneously  operate  bandwidth  intensive  applications  such  as  voice  and  video.  Applications  requiring 
a  lot  of  bandwidth  and  that  are  sensitive  to  interruptions,  such  as  voice  and  video  applications,  are  given 
priority  in  order  to  assure  quality.  The  manufacturer  claims  that  it  also  works  well  with  other  llg  and 
lln  protocol  wireless  products. 
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Table  3:  UAV  payload  and  ground  station  wireless  modem  specifications. 


Specification/Model 

TL-WN861N 

Form  Factor 

32-bit  Mini  PCI 

Standards 

IEEE  802.11n/g/b 

CSMA/CA  with  ACK 

Wireless  Signal  Rates 

With  Automatic  Fallback 

lln:270/243/216/162/108/8 1/54/27  Mbps 
135/21.5/108/81/54/40.5/27/13.5  Mbps 
130/117/104/78/52/39/26/13  Mbps 

65/58. 5/52/39/26/19. 5/13/6. 5  Mbps 
llg:54/48/36/24/18/12/9/6M  (adaptive) 
llb:ll/5.5/2/lM  (adaptive) 

Frequency  Range 

2.4-2.4835  GHz 

Wireless  Transmit  Power 

20  dBm  (max) 

Modulation  Type 

OFDM/CCK/16-QAM/64-QAM 

Receiver  Sensitivity 

270  m  -68dBm@10%PER 

130  m  -68  dBm@10%PER 

108  m  -68  dBm@10%PER 

54  m  -68  dBm@10%PER 

11  m  -85  dBm@8%PER 

6  m  -68  dBm@10%PER 
lm  -90  dBm@10%PER 

Security 

64/128/152  bit  WEP,  W P A/W P A/W PA2,  WPA- 
PSK/WPA2-PSK  (TKIP/AES) 

The  laboratory  benchtop  set-up  for  testing  the  authentication  protocols  between  the  two 
different  types  of  wireless  systems  is  shown  in  Figure  6. 


Ground  Station 
Processor  Unit  #1 


Ground  Station 
Processor  Unit  #2 


Payload  Processor  Unit 


Figure  6:  Benchtop  test  set-up. 
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Two  different  system  implementations  of  the  authentication  protocol  were  tested  -  with 
network  configurations  limited  to  just  two  nodes.  One  case  involved  the  use  of  two  ground  station  units 
as  might  be  deployed  in  a  mobile  ground  network.  The  other  case  employed  a  ground  station  and  a 
UAV  payload  to  represent  deployment  in  an  air-to-ground  network.  In  both  cases,  Prover  code  was 
installed  on  one  of  the  nodes,  while  Verifier  code  was  installed  on  the  other.  As  a  follow-on  test, 
installation  of  the  Prover  and  Verifier  code  was  switched  between  the  nodes  in  order  to  demonstrate 
that  a  node  could  function  as  either  a  Prover  or  Verifier.  Results  of  the  tests  run  are  discussed  in  the 
section  that  follows. 

Prior  to  protocol  testing,  the  configuration  of  the  LINUX  operating  systems  were  verified. 
Already  installed  on  each  system  was  LINUX  Fedora™  release-11  and  only  minor  software  updates  had 
to  be  made.  Compiling  the  ZKP  authentication  code  did  require  use  of  GMP  math  library  functions. 

GMP  is  a  free  library,  available  for  download  via  the  internet,  for  arbitrary  precision  arithmetic, 
operating  on  signed  integers,  rational  numbers  and  floating  point  numbers.  The  main  target 
applications  for  GMP  are  cryptographic  applications  and  research,  internet  security  and  algebraic 
systems  and  research  [14].  Installing  the  GMP  libraries  on  the  individual  systems  proved  to  be  problem. 

AFRL  policies  do  not  allow  for  unsecured  systems  to  be  connected  to  the  internet  so  direct 
download  of  the  GMP  files  was  not  a  possibility.  While  these  files  could  be  download  to  a  CD-Rom  via 
an  authorized  desktop  computer,  neither  the  UAV  payload  nor  the  Ground  Station  Units  were 
configured  to  support  installation  of  a  CD-Rom  drive.  In  the  end,  it  was  decided  to  download  the  GMP 
files  to  a  stand-alone  computer  system,  compile  the  C  code,  then  download  the  compiled  code  to  the 
UAV  payload  and  Ground  Station  processors  using  a  wired  Ethernet  connection.  This  hard-wired 
connection  was  disconnected  prior  to  wireless  testing. 
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4.0  Results  and  Discussion 


The  objective  of  this  short-duration  effort  involved  porting  a  ZKP-base  authentication  protocol  from  a 
desktop,  cabled  network  set-up  to  a  mobile,  wireless  network  configuration  for  the  purpose  of 
demonstrating  operation  over  a  wireless  communication  link.  The  expectations  were  that  a  successful 
outcome  would  provide  impetus  for  developing  a  more  detailed  plan  for  field  deployment  of  the 
protocol  using  mobile  (air  and  ground)  test  assets. 

The  authentication  protocol  consists  of  a  series  of  exchanges  between  two  entities:  a  Prover, 
and  a  Verifier  (as  was  described  in  Section  3  and  illustrated  in  Figure  2).  The  exchanges  that  occur  are 
made  observable  through  use  of  timestamps  that  are  output  to  display  consoles.  For  the  test  case 
involving  the  two  ground  stations,  the  resulting  exchange  reports  for  the  Prover  and  Verifier  are  shown 
in  Figures  7  and  8  respectively. 


Figure  7:  Prover  authentication  screen  display. 


Figure  8:  Verifier  authentication  screen  display. 
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Figure  9  and  Table  4  identify  and  describe  the  timestamps  generated  by  the  Prover's  code,  while 
Figure  10  and  Table  5  describe  the  timestamps  output  by  the  Verfier's  code. 


root®GeodelO:/homeZZKP_GOOD 

"1""*  > 

1  file  Edit  yiew  Terminal  Help 

[rootpGeodelO  ZKP_6000J#  ./zkpProverl37w 

Tiae  Elapsed:  2  as 

A 

Tiae  Elapsed:  4161  as 

^  (7\ 

Tiae  Elapsed:  4161  as 

Tiae  Elaosed:  4162  as 

^<7) 

Tiae  Elapsed:  4166  b$ 

Tiae  Elapsed:  4169  as 

\ 

[root@GeodelO  ZKP  GOOD)# 

(rootpGeodelO  ZKP  GOOOi# 

(rootpGeodelO  ZKP  GOOOl#  | 

( 

V 

<D 


Figure  9:  Prover  response  attribute. 


Table  4:  Verifier  response  timestamp  markers. 


Marker 

Description 

1 

1st  Timestamp:  Prover  establish  communications  connection 

2 

2nd  Timestamp:  Prover  sends/publishes  Public  Key 

3 

3rd  Timestamp:  Prover  sends/publishes  modulos  n 

4 

4th  Timestamp:  Prover  sends  witness  (x) 

5 

5th  Timestamp:  Prover  accepts  challenge  (a) 

6 

6th  Timestamp:  Prover  sends  response  (y) 
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rootOGeodeIO:/home/ZKP_GOOD 

1  file  Edit  yiew  Terminal  Help 

[root@jeodelO  ZKP_G0001#  ./zkpverifier 

Feige-Fiat-Shaair  ZKP  Iapleaentation: 

Network  Edition,  Version  1.1.3 

Verifier  waiting  for  Prover  access  request. , , 

A 
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Tiae  Elapsed:  1925  as 

. 

Tiae  Elapsed:  1926  as 

Tiae  Elapsed:  1929  as 

l 

Tiae  Elapsed:  1930  as 

Tiae  Elapsed:  1945  as 

Authentication  successful1 

Tiae  Elapsed:  1954  as 

Feige-Fiat-Shaair  ZKP  lapleaentation: 

Network  Edition,  Version  1.1.3 

Verifier  waiting  for  Prover  access  request... 

_ 

/7\ 

■  V 
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Figure  10:  Verifier  response  attributes. 


Table  5:  Verifier  response  timestamp  markers. 


Marker 

Description 

A 

Machine  is  awaiting  receipt  of  a  request 

1 

1st  Timestamp:  Start  counter  upon  receipt  of  a  request 

2 

2nd  Timestamp:  Verifier  receives  public  key 

3 

3rd  Timestamp:  Verifier  receives  modulos  n 

4 

4th  Timestamp:  Verifier  receives  witness  (x) 

5 

5th  Timestamp:  Verifier  sends  challenge  (a) 

6 

6th  Timestamp:  Verifier  receives  response  (y) 

B 

Verify  Authenticity  of  Prover 

7 

7th  Timestamp:  Elapsed  time  for  completing  authentication  protocol 

A' 

Machine  is  awaiting  receipt  of  a  request 
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An  example  screen  display  of  a  failed  authentication  attempt  is  provided  in  Figure  11.  In  this 
case,  the  Prover-Verifier  configuration  was  identical  to  that  described  above  i.e.,  two  ground  station 
systems  communication  over  a  wireless  link.  The  failure  was  ultimately  found  to  be  caused  by  having 
the  ground  station  units'  processor  board's  Ethernet  connection  enabled  at  the  time  that  the  RF  radio's 
wireless  connection  was  enabled.  A  hardwired  Ethernet  connection  was  made  between  the  two  units 
for  downloading  compiled  code  and  system  configuration  checking.  Disabling  the  Ethernet  connection 
via  an  operating  system  call  solved  the  protocol  failure  problem.  It  is  not  entirely  clear  why  having  both 
communication  channels  enabled  should  have  caused  a  failure. 


root@GeodelO:/home/ZKP_GOOD 


File  Edit  View  Terminal  Help 
[root@Geodel0  ZKP_G00D]#  ./zkpverifier 

Feige-Fiat-Shamir  ZKP  Implementation: 

Network  Edition,  Version  1.1.3 

Verifier  waiting  for  Prover  access  request. 

Time  Elapsed:  0  ms 

Time  Elapsed:  3963  ms 

Time  Elapsed:  3964  ms 

Time  Elapsed:  3964  ms 

Time  Elapsed:  3965  ms 

Time  Elapsed:  3965  ms 

Authentication  failed! 

Time  Elapsed:  3969  ms 

Feige-Fiat-Shamir  ZKP  Implementation: 

Network  Edition,  Version  1.1.3 

Verifier  waiting  for  Prover  access  request. 


Figure  11:  Verifier  unsuccessful  authentication  attempt  display. 


No  results  are  available  that  show  successful  demonstration  of  protocol  operation  between  a 
UAV  payload  system  and  ground  station.  The  two-node  configuration  only  worked  using  a  cabled 
Ethernet  connection  with  Prover  code  running  on  the  UAV  payload's  processor.  When  Verifier  code  was 
run  on  the  UAV  payload,  with  Prover  code  running  on  the  ground  station,  the  protocol  failed. 
Furthermore,  when  the  wireless  link  was  employed  the  demonstration  failed  regardless  of  whether 
Prover  or  Verifier  code  was  being  run  on  either  of  the  two  systems.  A  check  was  made  to  insure  that  the 
Ethernet  communication  path  was  disabled  and  to  eliminate  it  as  the  reason  for  failure.  More  time 
would  be  required  to  identify  why  use  of  the  payload  system  caused  such  problems. 
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5.0  Conclusions 


The  primary  objective  of  this  work  was  to  port  a  ZKP  authentication  protocol,  known  to  work  on  a 
desktop  computer  network,  onto  selected  embedded  processors  and  demonstrate  operations  over  a 
wireless  communications  link.  Given  the  short  duration  of  the  effort,  it  was  not  possible  to  complete  an 
exhaustive  performance  evaluation.  Suffice  it  to  say,  partial  success  was  achieved  in  that  protocol 
operations  were  fully  demonstrated  on  a  pair  of  Ground  Station  systems.  Unfortunately,  problems  were 
encountered  when  using  a  UAV-Ground  Station  pair.  With  only  a  limited  amount  of  in-house  resources 
available  to  carry  out  this  work,  no  further  investigations  could  be  carried  out  to  determine  the  reason 
for  protocol  inoperability.  Program  results  and  lessons-learned  are  summarized  below. 

•  The  selected  authentication  protocol  was  demonstrated  on  two  wireless  ground  station  nodes, 
each  having  identical  processing  and  wireless  radio  hardware.  Also  demonstrated  was  the 
ability  for  each  node  to  function  as  both  a  protocol  Prover  and  Verfier.  It  is  noted  that  the 
protocol  must  be  initiated  manually  at  each  of  the  two  nodes.  Additional  code  would  be  needed 
to  automate  the  process. 

•  During  testing  with  the  two  ground  station  nodes  it  was  noted  that  the  protocol  would  not 
operate  over  the  wireless  link  if  the  on-board  Ethernet  connection  was  enabled.  Disabling  the 
Ethernet  connection  via  an  operating  system  call  eliminated  this  problem.  Originally,  the 
Ethernet  connection  was  used  to  down-load  the  compiled  C++  authentication  protocol  code, 
then  disconnected  following  completion  system  verification  procedures  and  commencement  of 
wireless  testing.  The  Ethernet  connection  is  made  by  means  of  a  connection  on  the  PC-104 
processor  board,  while  the  wireless  connection  is  made  via  the  RF  radio  daughter-board;  two 
separate  connectors  on  two  different  boards.  Further  investigation  of  system  hardware  and 
software  configurations  is  warranted. 

•  Wireless  operation  of  the  protocol  between  a  ground  station  node  and  airborne  payload  node 
failed  to  be  demonstrated.  Bi-directional  wireless  communication  was  established  between  the 
two  nodes  as  evidenced  by  the  ability  of  each  node  to  "ping"  the  other.  As  was  previously 
noted,  the  UAV  payload  and  ground  station  were  not  implemented  using  identical  hardware. 

The  pinging  procedure  was  implemented  outside  of  the  authentication  protocol  code  which 
could  imply  that  there  may  be  something  unique  about  the  authentication  code  that  prevents 
its  operation  on  the  payload  system  hardware  -  perhaps,  the  manner  in  which  the 
communications  sockets  were  coded.  Further  investigation  of  this  problem  is  warranted. 

•  Furthermore,  testing  of  the  protocol  between  the  UAV  payload  and  ground  station  nodes  using 
a  wired  Ethernet  connection  was  only  partially  successful.  The  payload  system  could  only  be 
configured  to  function  as  a  Prover  and  not  as  a  Verifier  over  the  hard-wired  connection.  This 
problem  may  be  due  to  how  the  communication  sockets  are  set  up  or,  perhaps,  has  to  do  with 
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selection  of  the  wireless  versus  wired  communication  ports.  Further  investigation  of  this 
problem  is  warranted. 

Even  though  all  the  nodes  were  using  the  same  version  LINUX  operating  systems,  there  may  be 
some  features  that  are  impacted  by  node  system  hardware  and  (driver)  software  configurations. 
A  better  understanding  of  the  nuances  regarding  specific  system  implementations  may  be 
required,  especially  if  the  authentication  protocol  code  is  expected  to  be  run  on  a  variety  of 
processing  platforms.  Also,  a  better  understanding  of  the  integration  of  the  processing  and  RF 
radio  boards  may  be  required.  This  familiarity  can  only  be  gained  through  working  with  the 
various  devices. 
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6.0  Recommendations 


AFRL  Rome  Research  Site  technical  personnel  are  currently  pursuing  technology  investigations  involving 
the  use  of  small,  low  cost  UAV  technology.  Field  testing  of  novel  COTS-based  UAV  networking 
approaches  is  carried  out  at  AFRL's  Stockbridge  Test  Site.  Here,  data  collections  are  carried  out  to 
evaluate  link  performance,  develop  network  protocols  and  applications,  as  well  as  evaluate  their 
performance,  in  realistic  environments  [15].  The  availability  of  the  UAVs  and  the  Stockbridge  Test  Site 
provide  an  ideal  location  for  deploying  and  test  ZKP-based  authentication  protocols  in  air-to-air,  air-to- 
ground  and  mobile  on-the-ground  scenarios.  An  aerial  view  of  the  Test  Site,  showing  the  air  strip  used 
for  testing  the  small  UAVs,  is  provided  in  Figure  12.  Two  photographs  showing  typical  UAV  aircraft,  one 
in  the  field  while  and  another  opened-up  in  the  laboratory,  are  shown  in  Figure  13. 


Figure  12:  AFRL  Stockbridge  Test  Site. 


A)  Small  UAV  at  test  site.  B)  Small  UAV  payload  bay. 


Figure  13:  AFRL  small  UAVs. 
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Porting  of  the  ZKP  authentication  protocols  from  a  hardwired  desktop-centric  processing 
environment  to  a  wireless  mobile  environment  demonstrated  that  the  protocols  can  be  easily  migrated 
to  systems  designed  and  built  for  use  with  small  UAVs.  Furthermore,  by  making  use  of  existing  UAV  test 
program  assets  the  cost  and  risk  of  deploying  a  working  wireless  data  link  between  a  UAV  and  mobile 
ground  station  can  be  minimized.  As  has  been  noted  earlier,  some  problems  have  been  encountered 
when  attempting  to  operate  the  ZKP  protocol  between  systems  employing  different  CPU  boards.  This 
problem  is  considered  to  be  minor  a  minor  one  and,  with  some  small  amount  of  additional  effort,  should 
be  easily  corrected.  If  follow-on  protocol  development  work  will  be  directed  towards  deployment  on 
AFRL's  UAV  platforms  then  the  work  needs  to  be  coordinated  with  processor  payload  designs  being 
developed  for  use  under  the  small  UAV  program. 

AFRL  technical  personnel  are  currently  assembling  new  Ground  Station  and  UAV  payload 
systems.  Next  generation  ground  station  designs  make  use  of  the  same  processor  boards  and  upgraded 
wireless  radio  boards.  An  example  of  one  such  unit  is  shown  in  Figure  14.  Given  the  noted  difficulties  in 
operating  the  authentication  protocols  on  different  processing  and  wireless  system  configurations, 
future  protocol  integration  work  should  be  carried  out  on  the  physical  hardware  that  will  be  deployed  in 
the  field.  Therefore,  protocol  development  should  be  worked  in  parallel  with  UAV  program  UAV 
payload  and  ground  station  design  and  development. 


B)  Ground  Station  Processor 


A)  Ground  Station 


Figure  14:  Upgraded  ground  station. 
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UAV  payload  designs  have  not  progressed  to  the  point  where  a  decision  can  be  made  regarding 
the  selection  of  hardware.  Two  candidate  platforms  have  been  procured  for  evaluation  purposes:  Via 
Technologies®  ARTiGo  A1150™,  which  includes  a  full  64-bit  dual  core  processor  and  support  Wi-Fi 
communications;  and  Embedded  Systems  TS-4800™  controlled  board,  featuring  an  800  MHz  ARM™ 
processor  and  capable  accepting  a  Wi-Fi  capable  wireless  daughter  board.  The  two  devices  are  shown  in 
Figures  15  and  16  respectively. 


Figure  15:  Upgraded  payload  package. 


Figure  16:  Miniature  Processor  payload. 


Even  though  all  of  the  above  mentioned  systems  are  capable  of  running  LINUX  operating 
systems,  the  configuration  of  software  drivers  and  hardware  devices  may  impact  the  operation  of  the 
authentication  protocols.  It  would  be  beneficial  to  evaluate  both  the  operating  systems,  hardware 
devices  and  authentication  protocol,  simultaneously,  in  order  minimize  integration  problems.  A  more 
detailed  test  plan  should  be  developed  to  guide  future  deployment  of  ZKP-based  authentication 
protocols. 


Approved  for  Public  Release;  Distribution  Unlimited. 
20 


7.0  References 


[1]  Liu,  L.  "  Security  and  Trust  Management  in  Self-organizing  Wireless  Ad  hoc  Networks",  AFRL 
Workshop  Paper,  College  of  Computing,  Georgia  Institute  of  Technology.  2009. 

[2]  Aboudagga,  N.,  Rafaei,  M.,  Eltoweissy,  M.,  DaSilva  L.,  and  Quisquater,  J.,  "  Authentication  Protocols 
for  Ad  Hoc  Networks:  Taxonomy  and  Research  Issues",  Q2SWinet  '05  Proceedings  of  the  1st  ACM 
international  workshop  on  Quality  of  service  &  security  in  wireless  and  mobile  networks,  p.  1,  2005. 

[3]  Hegland,  A.,  Winjum,  E.,  Hedenstad,  O.,  "A  Framework  for  Authentication  in  NBD  Tactical  Ad  Hoc 
Networks",  IEEE  Communications  Magazine,  October  2011,  p.  64. 

[4]  Feige,  U.,  Fiat,  A.,  Shamir,  A.,  "Zero-Knowledge  Poofs  of  Identity",  Journal  of  Cryptology,  1988, 
p.77-94. 

[5]  Raffo,  D.,  "Digital  Certificates  and  the  Feige-Fiat-Shamir  Zero-Knowledge  Protocol",  Labratoire 
d'lnformatique,  Ecole  Polytechnique,  France,  pp.  37-56,  2002. 

[6]  Rowe,  N.,  unpublished  work  regarding  implementation  of  FFS  ZKP  protocols  on  TCP/IP  networks, 
2009. 

[7]  Kizza,  J.M.,  "Feige-Fiat-Shamir  ZKP  Scheme  Revisited",  International  Journal  of  Computing  and  ICT 
Research,  Vol.  4,  No.  1,  p.  9,  June  2010. 

[8]  AFRL-RI-TR-2011-178,  "Airborne  Network  Trust  Using  Zero  Knowledge  Techniques",  Northrop 
Grumman  Systems  Co.,  Reily,  M.,  Card,  S.,  p.  61. 

[9]  Aronsson,  H.  A.,  "Zero  Knowledge  Protocols  and  Small  Systems",  Department  of  Computer  Science, 
Helsinki  University  of  Technology,  http://www.tml.tkk.fi/Opinnot/Tik- 
110.501/1995/zeroknowledge.html . 

[10]  Liu,  L.,  ibid,  p2. 

[11]  Aidi,  L.  Changsu,  J.  "  Delay  Tolerant  Network",  School  of  Information  and  Communication 
Technology  KTH,  Stockholm,  Sweden,  2011,  http://www.slideshare.net/lailiaidi/delay-tolerant-network- 
11484982 . 

[12]  PM-945GSE-N270  Users  Manual,  IEI  Technology  Corporation,  17  August  2011. 

[13]  TL-WN861N  Data  Sheet,  TP-LINK®,  www.tp-link.com  . 

[14]  The  GNU  Multiple  Precision  Arithmetic  Library,  http://gmplib.org/  . 

[15]  Hague,  D.,  Kung,  H.T.,  Suter,  B.,  "Field  Experimentation  of  COTS-Based  UAV  Networking",  IEEE 
MILCOM  2006. 


Approved  for  Public  Release;  Distribution  Unlimited. 
21 


Appendix  A:  ZKP  Prover  Code 
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ZKP_  PROVER/Makefile 


#  Makefile  for  the  FFS  Zero-Knowledge  Identification  Scheme  implementation 
CC  =  gee 

LIBS  =  /usr/local/lib/libgmp.a 

zkp:  zkp.o  center.o  prover.o 

$(CC)  zkp.c  center.c  prover.c  -o  zkp  -lm  $(LIBS) 

clean: 

clear;  rm  -f  zkp  *.o  core 
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ZKP_  PROVER/zkp.h 


tdefine  TRUE  1 
tdefine  FALSE  0 

/*  Multiplicity  of  challenge  */ 
tdefine  K  10 

/*  Number  of  rounds  of  the  protocol  */ 
tdefine  T  1 


mpz  t  n;  /*  modulus  (a  Blum  integer)  */ 

mpz  t  i [K] ;  /*  Prover's  public  key  */ 

mpz  t  rndseed; 


void  setrndseed ( ) ; 
void  publish  modulus ()  ; 
void  compute_keys ()  ; 
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ZKP_  PROVER/center.  c 


tinclude  <stdlib.h> 

#include  <stdio.h> 

#include  <time.h> 
tinclude  <gmp.h> 
tinclude  "zkp.h" 

/* 

Publish  the  modulus  (a  Blum  integer  which  prime  factors 
are  randomly  chosen  and  512  bits  long) 

*/ 

void  publish  modulus ()  { 

mpz  t  rand,  tmpprime,  tmp,  primel,  prime2; 
gmp_randstate_t  state; 

mpz  init (rand) ; 
mpz  init (tmpprime) ; 
mpz  init (tmp)  ; 
mpz  init (primel)  ; 
mpz  init (prime2)  ; 
mpz  init (n)  ; 

gmp  randinit  lc  2exp  size (state,  128); 

/*  computes  1st  prime  */ 
setrndseed ( ) ; 

gmp_randseed ( state ,  rndseed); 
mpz  rrandomb (rand,  state,  512); 

while  (1)  {  /*  repeat  until  prime  is  of 

form  4r+3  */ 

mpz  nextprime (tmpprime,  rand) ; 
mpz  sub  ui (tmp,  tmpprime,  3) ; 
if  (mpz  divisible  ui  p (tmp,  4))  break; 
mpz  set (rand,  tmpprime); 

} 

mpz  set (primel,  tmpprime); 

/*  computes  2nd  prime  */ 
setrndseed ( ) ; 

gmp_randseed ( state ,  rndseed); 
mpz  rrandomb (rand,  state,  512); 
while  (1)  { 

mpz  nextprime (tmpprime,  rand)  ; 
mpz  sub  ui (tmp,  tmpprime,  3) ; 
if  (mpz  divisible  ui  p (tmp,  4))  break; 
mpz  set (rand,  tmpprime); 

} 

mpz  set(prime2,  tmpprime); 
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/*  computes  modulus  */ 
mpz  mul (n,  primel,  prime2); 

//gmp  printf ( "Publishing  modulus: 

/ /mpz_clear (rand) ; 

//mpz  clear (tmpprime) ; 

//mpz_clear (tmp) ; 

//mpz  clear (primel ) ; 

//mpz  clear (prime2 ) ; 
//gmp_randclear ( state)  ; 


%Zd\n\n" ,  n)  ; 
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ZKP_  PROVER/pro  ver.  c 


tinclude  <stdlib.h> 

#include  <stdio.h> 

#include  <gmp.h> 

#include  "zkp.h" 

static  mpz_t  s [K] ;  /*  private  key  */ 

static  mpz  t  r;  /*  random  number  */ 


/* 

Choose  private  and  public  key 

*/ 

void  compute_keys ( )  { 

int  index  =  0,  index2,  flag; 
mpz  t  candidate,  inverse; 
gmp_randstate_t  state; 

//printf ( "Computing  keys  "); 

gmp  randinit  lc  2exp  size (state,  128); 
setrndseed ( ) ; 

gmp_randseed ( state ,  rndseed) ; 
mpz  init (candidate)  ; 
mpz  init (inverse) ; 

while  (index  <  K)  { 

/ / printf  ( " .  " )  ; 
mpz  init (i [index]  )  ; 
mpz  init (s [index] ) ; 

mpz  urandomm (candidate,  state,  n)  ; 

/*  test  if  candidate  has  already  been  chosen  as  key  component  */ 
flag  =  FALSE; 

for  (index2  =  index  -  1;  index2  >=  0;  index2--)  { 
if  (mpz  cmp ( s [ index2 ] ,  candidate)  ==  0)  { 

flag  =  TRUE; 
break; 


if  (flag  ==  TRUE)  continue; 

mpz  mul (inverse,  candidate,  candidate) ; 
mpz  modfinverse,  inverse,  n)  ; 

if  (mpz  invert (inverse,  inverse,  n)  ==  0)  continue; 

mpz_set ( s [ index] ,  candidate); 
mpz  set ( i [ index] ,  inverse); 
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index++; 


} 

//printf ( " \n\nPublic  key : \n" ) ; 

//  for  (index  =  0;  index  <  K;  index++) 

//{ 

/ / gmp  printf (" %Zd\n"  ,  i [index]); 

//printf ("size  of  i:  %d" ,  (sizeof  (i) /sizeof (i [ 0] ) ) ) ; 

//} 

//printf (" Private  key:\n"); 

//for  (index  =  0;  index  <  K;  index  +  +)  gmp  printf ( "%Zd\n" ,  s [index]); 


/// // /////// /////// //////// ///// /////// ////// /  run  at  program  close  to 
clear : 

//mpz_clear (candidate) ; 

//mpz  clear (inverse)  ; 

//gmp_randclear ( state)  ; 


/* 

Pick  a  random  number  and  send  the  witness  x  (step  1  of  the  protocol) 

*/ 

void  witness (mpz  t  x)  { 
gmp_randstate_t  state; 

mpz  init (r) ; 
mpz  init (x) ; 

gmp  randinit  lc  2exp  size (state,  128); 
setrndseed ( ) ; 

gmp_randseed ( state ,  rndseed) ; 

mpz  urandomm(r,  state,  n)  ; 
mpz  mul (x,  r,  r)  ; 
mpz  mod (x,  x,  n)  ; 

//gmp  printf (" \nWitness  :  %Zd\n\n",  x) ; 

//gmp_randclear ( state)  ; 

//return  x; 

} 


/* 

Send  the  response  y  (step  3  of  the  protocol) 

*/ 

void  response (mpz  t  y,  unsigned  int  e) 

{ 

int  index; 
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mpz_set (y,  r )  ; 


for  (index  =  0;  index  <  K; 

{ 

if  (e  &  (0x1  <<  index)  ) 

mpz_mul (y,  y,  s [index]) 

} 

mpz_mod(y,  y,  n)  ; 

//gmp  printf ( "Response  : 


index++ ) 


%Zd\n\n" ,  y)  ; 
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ZKP_  PROVER/zkp.c 


tinclude  <unistd.h> 

#include  <stdlib.h> 

#include  <stdio.h> 
tinclude  <stdint.h> 
tinclude  <gmp.h> 
tinclude  <time.h> 
tinclude  <sys/time.h> 

#include  "zkp.h" 

//network  includes 
#include  <sys/types . h> 

#include  <sys/socket . h> 

#include  <netinet/in . h> 

#include  <netdb.h> 

/kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 
k  k  k  k  k  k 

Feige-Fiat-Shamir  (FFS)  Zero  Knowledge  (ZK)  Identification  Scheme: 
Networked  Implementation: 

Original  by  Daniele  Raffo,  25  JUN  2002  -  LIX,  Ecole 
Polytechnique 

Expanded  by  Nathaniel  Rowe,  11  JAN  2012  -  AFRL  Rome 

This  networked  implementation  uses  the  same  FFS  ZK  format,  but  is 
setup 

to  function  over  a  TCP/IP  based  network.  ZK  is  preserved. 

This  program  is  the  ***CLIENT  /  PROVER***  edition 

•k'k'k'k'k'k'kk'k'k'k'k'k'k'k'kk'k'k'k'k'k'k'kk'k'k'k'k'k'k'k'k'k'k'k'k'k'kk'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'kk'k'k'k'k'k'kk'k'k'k'k'k 
k  k  k  k  k  I 

uint32_t  stampstart  ()  ; 

uint32_t  stampstop (uint32_t  start); 

int  fastseed  =  TRUE; 

int  main (int  argc,  char  **argv)  { 

size_t  words; 
int  proof,  temp; 
unsigned  int  e; 
mp  z  t  x  ; 
mp  z_t  y ; 

uint32_t  start,  stop; 
mpz  init  (x) ; 
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/*  random  boolean  vector  (challenge)  */ 
/*  witness  */ 

/*  response  */ 

//time  stamp  start  and  stop 


mpz_init (y) ; 

mpz  init (rndseed) ; 

//START  TIME  TIMESTAMP 
start  =  stampstart ( ) ; 

/******************  START  NETWORK  SETUP  ******************/ 
int  sockfd,  portno,  s; 
struct  sockaddr  in  serv  addr; 

portno  =  12303; 

sockfd  =  socket (AF_INET,  SOCK_STREAM,  0); 
serv  addr. sin  family  =  AF  INET; 

serv  addr. sin  addr . s  addr  =  inet  addr ( "127 . 0 . 0 . 1 ") ; 
serv  addr. sin  port  =  htons (portno) ; 

s  =  connect ( sockfd,  &serv_addr,  sizeof  (serv_addr) ) ; 
if  ( s<0 ) 

printf ( "Prover :  Connection  Failed\n"); 
/******************  END  network  SETUP  ******************/ 

stop  =  stampstop ( start ) ; 

int  t  var  =  T; 

for (t_var;  t_var  >  0;  t_var — )  //START  FOR  LOOP  FOR  T 
{ 


mpz  init (rndseed) ; 
mpz_init (y) ; 
mpz  init (x) ; 

publish  modulus () ;  /*  Prover  publishes  modulus  n 

/ 

compute  keys();  /*  Prover  chooses  public/private  keys 

/ 

witness (x) ;  /*  Prover  sets  x  */ 

/******************  START  Send  Public  Key  ******************/ 

char  buffer[128]; 

for (temp  =  0;  temp  <  K;  temp++) 

{ 

//printf ( "\n\nPacket  data  before\n"); 

/ /gmp_printf ( "%Zd\n" ,  i [temp] ) ; 

mpz_export (buf f er ,  Swords,  1,  128,  0,  0,  i[temp]);  //export 
s  =  write (sockfd,  buffer,  sizeof (buffer) ) ;  //write  to  stream 

if  (s<0) 

printf ( "Prover :  Public  Key  Write  Failed\n"); 
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usleep (200)  ; 


} 

//printf ( " \n\nPublic  Key : \n" ) ; 

//for (temp  =  0;  tempCK;  temp++)  gmp  printf ( "%Zd\n\n" ,  i[temp]); 
/******************  STOP  Send  Public  Key  ******************/ 

stop  =  stampstop (start) ; 

/******************  START 
memset (buffer,  0,  128); 
mpz  export (buffer,  Swords, 
array 

s  =  write ( sockfd,  buffer,  sizeof  (buffer)  ) ; 
if  (s<0) 

printf (" Prover :  Modulus  Write  Failed\n"); 

//printf ( "Modulus :  "); 

//gmp  printf ( "%Zd\n"  ,  n)  ; 

/******************  STOP  Send  Modulus  ******************/ 
stop  =  stampstop ( start )  ; 

/******************  START  Send  Witness  ******************/ 
memset (buffer,  0,  128); 

mpz_export (buffer,  Swords,  1,  128,  0,  0,  x) ;  //export  'x'  to  a  char 
array 

s  =  write ( sockfd,  buffer,  sizeof (buffer) ) ; 
if  (s<0) 

printf (" Prover :  X  Write  Failed\n"); 

//printf ( "Witness  :  "); 

//gmp  printf ( "%Zd\n"  ,  x)  ; 

/******************  STOP  Send  Witness  ******************/ 
stop  =  stampstop ( start )  ; 

/******************  START  Get  Challenge  Bitmask  ******************/ 
char  rxbuffer[K]; 
unsigned  long  total  =  0x0; 
int  i  =  0; 

//mpz_t  total;  /*  response  */ 

/ /mpz_init (total )  ; 
total  =  0x0; 

s  =  read (sockfd,  rxbuffer,  K)  ; 
if  (s<0) 

printf ( "Prover :  Challenge  Read  Failed\n"); 

for (i;  i  <  K;  i++) 

{ 

if (rxbuffer [i] ) 


Send  Modulus  ******************/ 

1,  128,  0,  0,  n) ;  //export  'n'  to  a  char 


Approved  for  Public  Release;  Distribution  Unlimited. 
32 


total  |=  (Oxl  <<  i); 


} 

//printf ("%d\n" ,  total); 

/******************  ST0P  Get  challenge  Bitmask  ******************/ 
stop  =  stampstop ( start )  ; 

/********************  START  Send  Response  Y  *******************/ 
response (y,  total);  /*  Prover  sends  response  to 

Verifier  */ 

memset (buffer,  0,  128); 

mpz_export (buffer,  Swords,  1,  128,  0,  0,  y) ;  //export  'y'  to  a  char 
array 

s  =  write ( sockfd,  buffer,  sizeof  (buffer)  ) ; 
if  (s<0) 

printf (" Prover :  Write  Failed  for  Y\n"); 

//gmp  printf ( "Response  x  :  %Zd\n\n",  x) ; 

//gmp_printf ( "Response  y  :  %Zd\n\n",  y) ; 

//printf ("total  :  %d\n",  total); 


stop  =  stampstop ( start )  ; 

usleep (1000000) ;  //let  local  clock  advance  to  ensure 

randomness 


}  //  END  FOR  LOOP  FOR  T 


mpz  clear (x) ; 
mpz_clear (y)  ; 
mpz  clear (rndseed); 


close ( sockfd)  ; 
return  ( 0 )  ; 


/********************  STOP  Send  Response  Y 
/* 

Set  the  random  seed  from  /dev/random 

*/ 

void  setrndseed() 


•k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k  j 


FILE  *rnd; 
mpz  t  rndtmp; 
unsigned  long  int  idx; 
time_t  tl; 

if  ( ! f astseed)  { 
mpz  init (rndtmp) ; 
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rnd  =  fopen ( "/dev/random" , 


r")  ; 


for  (idx  =  0;  idx  <  128;  idx++)  { 

mpz  set  ui (rndtmp,  (unsigned  long  int)  getc(rnd)); 

mpz  mul  2exp (rndtmp,  rndtmp,  idx  *  8);  /*  left  shift  */ 

mpz  add(rndseed,  rndseed,  rndtmp); 


fclose (rnd)  ; 

//mpz  clear (rndtmp); 


else  { 

/*  Set  a  faster  seed.  Do  not  use  this  for  cryptographic  purposes 

*/ 

mpz  set  ui (rndseed,  (unsigned  long  int)  time(Stl)); 

mpz  mul  ui  (rndseed,  rndseed,  (unsigned  long  int)  getpidO); 

mpz  mul  ui (rndseed,  rndseed,  (unsigned  long  int)  getppidO); 


//Modified  from  www.codealias.info  15  July  2009 
uint32_t  stampstart() 

{ 

struct  timeval  tv; 
struct  timezone  tz; 
struct  tm  *tm; 
uint32_t  start; 

gettimeof day ( &tv,  &tz)  ; 
tm  =  localtime ( &tv . tv  sec)  ; 

start  =  tm->tm  hour  *  3600  *  1000  +  tm->tm  min  *  60  *  1000  +  tm- 
>tm_sec 

*  1000  +  tv.tv_usec  /  1000; 
return  (start) ; 

} 


uint32_t  stampstop (uint32_t  start) 

{ 


struct  timeval  tv; 
struct  timezone  tz; 
struct  tm  *tm; 
uint32_t  stop; 
uint32_t  elapsed; 


gettimeof day ( &tv,  &tz)  ; 
tm  =  localtime ( &tv . tv  sec)  ; 
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stop  =  tm->tm  hour  *  3600  *  1000  +  tm->tm  min  *  60  *  1000  +  tm- 
>tm_sec 

*  1000  +  tv.tv_usec  /  1000; 
elapsed  =  stop  -  start; 

printf("Time  Elapsed:  %d  ms\n",  elapsed); 
usleep (100) ; 


Approved  for  Public  Release;  Distribution  Unlimited. 
35 


Appendix  B:  ZKP  Verifier  Code 
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ZKP_  VE  RIFIER/ Makefile 


#  Makefile  for  the  FFS  Zero-Knowledge  Identification  Scheme 
implementation 

CC  =  gcc 

LIBS  =  /usr/local/lib/libgmp. a 

zkp:  zkp.o  verifier. o 

$ (CC)  zkp.c  verifier. c  -o  zkp  -lm  $  (LIBS) 

clean : 

clear;  rm  -f  zkp  *.o  core 
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ZKP_  VERIFIER/zkp.  h 


tdefine  TRUE  1 
tdefine  FALSE  0 

/*  Multiplicity  of  challenge  */ 
tdefine  K  10 

/*  Number  of  rounds  of  the  protocol  */ 
tdefine  T  1 


mpz  t  n;  /*  modulus  (a  Blum  integer)  */ 

mpz  t  i [K] ;  /*  Prover's  public  key  */ 

mpz  t  rndseed; 

void  setrndseed ( ) ; 
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ZKP_  VERIFIER/verifier.  c 


tinclude  <stdlib.h> 

#include  <stdio.h> 

#include  <gmp.h> 

#include  "zkp.h" 

/* 

Sends  a  random  bit  vector  as  the  challenge  (step  2  of  the  protocol) 

*/ 

unsigned  int  challenge () 

{ 


//return  (bitmask); 

} 


/* 

Verifies  the  response  from  Prover  (step  4  of  the  protocol) 

*/ 

int  verify (mpz  t  x,  mpz  t  y,  unsigned  int  e)  { 

int  index,  result  =  FALSE; 
mpz_t  test; 
mpz_init (test) ; 

mpz_mul (test,  y,  y) ; 

for  (index  =  0;  index  <  K;  index++) 

{ 

if  (e  &  (0x1  <<  index))  mpz  mul (test,  test,  i [index]); 

} 

mpz_mod (test,  test,  n)  ; 

//gmp  printf ( "Verification :  %Zd\n\n",  test); 
if  (mpz  cmp (x,  test)  ==  0)  result  =  TRUE; 
mpz_clear (test) ; 

return  (result) ; 

} 


Approved  for  Public  Release;  Distribution  Unlimited. 
39 


ZKP_  VERIFIER/zkp.  c 


#include 

#include 

tinclude 

tinclude 

tinclude 

#include 

#include 

tinclude 

#include 


<unistd . h> 
<stdlib . h> 
<stdio . h> 
<stdint . h> 
<gmp . h> 

<math . h> 
<time . h> 
<sys/ time . h> 
" zkp . h" 


//network  includes 
#include  <sys/types . h> 
#include  <sys/socket . h> 
#include  <netinet/in . h> 
#include  <netdb.h> 


/kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 
k  k  k  k  k  k 

Feige-Fiat-Shamir  (FFS)  Zero  Knowledge  (ZK)  Identification  Scheme: 
Networked  Implementation: 

Original  by  Daniele  Raffo,  25  JUN  2002  -  LIX,  Ecole  Polytechnique 
Expanded  by  Nathaniel  Rowe,  11  JAN  2012  -  AFRL  Rome 

This  networked  implementation  uses  the  same  FFS  ZK  format,  but  is 
setup 

to  function  over  a  TCP/IP  based  network.  ZK  is  preserved. 

This  program  is  the  ***SERVER  /  VERIFIER***  edition 
Version  Information:  Version  1.1.3 
Version  Details: 

Successful  ZK  authentication  between  two  networked  machines. 

Fixed 

a  bug  that  causes  intermittent  bignum  errors .  Fixed  a  network 

hang 

bug  and  now  allows  continually  authentication  at  the  Verifier. 

Also 

now  removing  key  information  from  memory  for  additional  security. 
Future  Release: 

-Make  it  easier  to  adjust  size  of  FFS  'K'  vector 
-Check  use  of  'T'  vector  for  inconsistencies 

-Import  secret  keys  from  txt  files  so  they  are  not  transmitted 
at  the  start  of  each  exchange. 

k'k'k'k'k'k'k'kk'k'k'k'k'k'kk'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'kk'k'k'k'k'k'k'k'k'kk'k'k'k'k 
k  k  k  k  k  I 
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uint32_t  stampstart () ; 

uint32_t  stampstop (uint32_t  start); 

int  fastseed  =  TRUE; 

int  main (int  argc,  char  **argv)  { 

unsigned  int  e;  /*  random  boolean  vector  (challenge)  */ 

int  proof,  s,  temp; 

uint32_t  start,  stop;  //time  stamp  start  and  stop 
/ / rnd  seed  was  here 
char  buffer[128]; 

mpz_t  yt;  /*  define  */ 

mpz  t  xt; 

/*********************  SETUP  NETWORK  *******************/ 

int  sockfd,  newsockfd,  portno,  clilen,  binder; 

struct  sockaddr  in  serv  addr,  cli  addr; 

clilen  =  sizeof (cli  addr) ; 

portno  =  12303; 

sockfd  =  socket (AF_INET,  SOCK_STREAM,  0); 
serv  addr. sin  family  =  AF  INET; 

serv  addr. sin  addr . s  addr  =  htonl(INADDR  ANY); 
serv  addr. sin  port  =  htons (portno) ; 

//bind  the  given  port 

binder  =  bind(sockfd,  (struct  sockaddr  *)  Sserv  addr, 
sizeof (serv_addr) ) ; 
if  (binder  <  0) 

printf ( "Verifier :  Bind  Failed"); 

while (TRUE)  //start  loop  to  continually  accept 

connections 

{ 

printf (" \nFeige-Fiat-Shamir  ZKP  Implementation : \n" ) ; 
printf ( "Network  Edition,  Version  1.1.2\n"); 

printf ( "Verifier  waiting  for  Prover  access  request ... \n" ) ; 
listen (sockfd,  1); 

newsockfd  =  accept ( sockfd,  (struct  sockaddr  *)  &cli_addr,  Sclilen) ; 
if (newsockfd  <  0) 

printf ( "Verifier :  Socket  Accept  Failure"); 

/******************  END  network  SETUP  ******************/ 

//START  TIME  TIMESTAMP: 
start  =  stampstart () ; 

stop  =  stampstop ( start ) ;  //first  timestamp 
int  t  var  =  T; 
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for (t_var;  t_var  >  0;  t_var — )  //START  'FOR  LOOP'  FOR  T,  CLOSE  -LINE 
178 
{ 

mpz  init (rndseed) ;  //initialize  random  seed 
mpz  init (xt) ; 
mpz_init (yt) ; 

/*******************  START  Get  Public  Keys  *********************/ 
for (temp  =  0;  temp  <  K;  temp++) 

{ 

s  =  read (newsockf d,  buffer,  128); 

mpz_import (i [temp] ,  1,  1,  128,  0,  0,  buffer);  //import  'public 
key'  from  char  buf 

memset (buf f er ,  0,  128); 
usleep (200)  ; 

} 

//printf (" \n\nPublic  key : \n" ) ; 

//for  (temp  =  0;  temp  <  K;  temp++)  gmp  printf ( "%Zd\n\n" ,  i [temp] ) ; 
/*******************  END  Get  Public  Keys  *********************/ 

stop  =  stampstop ( start ) ;  //second  timestamp 

/*******************  START  Get  Publishing  Modulus 

•k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k  J 

memset (buffer,  0,  128); 
s  =  read (newsockf d,  buffer,  128); 

mpz  import (n,  1,  1,  128,  0,  0,  buffer);  //import  'n'  from  char  buf 
//gmp  printf (" Publishing  modulus:  %Zd\n\n",  n) ; 

/*******************  END  Get  Publishing  Modulus 

'k-k'k-k-k-k-k'k'k'k-k'k'k-k-k-k'k-k'k-k-k  j 

stop  =  stampstop ( start ) ;  //third  timestamp 

/*******************  START  Get  Witness  *********************/ 
memset (buffer,  0,  128); 
mpz  init (xt)  ; 

s  =  read (newsockf d,  buffer,  128); 

mpz  import (xt,  1,  1,  128,  0,  0,  buffer);  //import  'x'  from  char  buf 
//gmp  printf ( "Received  Witness:  %Zd\n\n",  xt) ; 

/*******************  END  Get  Witness  *********************/ 

stop  =  stampstop ( start ) ;  //fourth  timestamp 

/*******************  START  Send  Challenge  *********************/ 
unsigned  int  index,  bit; 
unsigned  long  bitmask  =  0x0; 
char  bitvector [K] ; 

setrndseed ( ) ; 

srandom (  (unsigned  int)  mpz  get  ui (rndseed)  )  ; 
for  (index  =  0;  index  <  K;  index++) 
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{ 

bit  =  (int) ( random ()  %  2); 
if  (bit) 

{ 

bitvector [ index]  =  OxFF; 
bitmask  |=  (Oxl  <<  index); 

} 

else 

{ 

bitvector [ index]  =  0x00; 

} 

//printf ( "%d" ,  bit); 

} 

//printf (" \nBITMASK :  %d\n",  bitmask); 

//now  we  send  the  challenge  back  to  the  prover 
s  =  write (newsockfd,  bitvector,  K)  ; 

/*******************  END  send  Challenge  *********************/ 
stop  =  stampstop ( start ) ;  //fifth  timestamp 

/*******************  START  Get  Response  *********************/ 
memset (buffer,  0,  128); 

s  =  read (newsockfd,  buffer,  sizeof  (buffer) ) ;  //get  response  from 
prover 


mpz  init  (yt)  ;  /*  initialize  */ 

mpz  import (yt,  1,  1,  128,  0,  0,  buffer);  //import  'y'  from  buffer 

//gmp  printf ( "Response  xt  :  %Zd\n\n",  xt)  ; 

//gmp_printf ( "Response  yt  :  %Zd\n\n",  yt) ; 

//printf ("total  :  %d\n",  e)  ; 

/********************  END  Get  Response  *********************/ 
stop  =  stampstop ( start ) ;  //sixth  timestamp 

/*******************  VERIFY  AUTHENTICATION  ********************/ 
proof  =  verify (xt,  yt,  bitmask);  /*  Verifier  verifies  if 

response  matches  */ 

if  (proof) 

printf ( "Authentication  successful!\n") ; 
else 

printf ( "Authentication  failed! \n") ; 

stop  =  stampstop ( start ) ;  //seventh  timestamp 

}  //END  FOR  LOOP  FOR  T 

mpz_clear (xt) ; 
mpz_clear (yt)  ; 
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mpz  clear ( rndseed)  ; 


close (newsockfd)  ; 

} 

return  ( 0 ) ; 

} 

/*******************  END  VERIFY  AUTHENTICATION  ********************/ 


/*******************  Random  Seed  Determination 

•k-k-k'k'k-k'k'k'k'k'k'k'k-k-k'k'k-k'k'k'k  j 

//Set  the  random  seed  from  /dev/random 

void  setrndseed()  { 

FILE  *rnd; 
mpz  t  rndtmp; 
unsigned  long  int  idx; 
time_t  tl; 

if  ( ! f astseed)  { 
mpz  init (rndtmp) ; 

rnd  =  f open ( " /dev/random" ,  "r"); 

for  (idx  =  0;  idx  <  128;  idx++)  { 

mpz  set  ui (rndtmp,  (unsigned  long  int)  getc(rnd)); 

mpz  mul  2exp (rndtmp,  rndtmp,  idx  *  8);  /*  left  shift  */ 

mpz  add(rndseed,  rndseed,  rndtmp); 

} 

fclose (rnd) ; 

mpz  clear (rndtmp) ; 

} 

else  { 

/*  Set  a  faster  seed.  Do  not  use  this  for  cryptographic  purposes! 

*/ 

mpz  set  ui (rndseed,  (unsigned  long  int)  time(Stl)); 

mpz  mul  ui  (rndseed,  rndseed,  (unsigned  long  int)  getpidO); 

mpz  mul  ui (rndseed,  rndseed,  (unsigned  long  int)  getppidO); 

} 

} 

/*******************  Time  Stamping  *********************/ 
//Modified  from  www.codealias.info  15  July  2009 
uint32_t  stampstart() 

{ 

struct  timeval  tv; 
struct  timezone  tz; 
struct  tm  *tm; 
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uint32  t  start; 


gettimeof day ( &tv,  &tz) ; 
tm  =  localtime ( &tv . tv  sec)  ; 

start  =  tm->tm  hour  *  3600  *  1000  +  tm->tm  min  *  60  *  1000  +  tm- 
>tm_sec 

*  1000  +  tv.tv_usec  /  1000; 
return  ( start) ; 

} 


uint32_t  stampstop (uint32_t  start) 


struct  timeval  tv; 
struct  timezone  tz; 
struct  tm  *tm; 
uint32_t  stop; 
uint32_t  elapsed; 


gettimeof day ( &tv,  &tz)  ; 
tm  =  localtime ( &tv . tv  sec)  ; 


stop  =  tm->tm  hour  *  3600  *  1000  +  tm->tm  min  *  60  *  1000  +  tm- 
>tm_sec 

*  1000  +  tv.tv_usec  /  1000; 
elapsed  =  stop  -  start; 

printf("Time  Elapsed:  %d  ms\n",  elapsed); 


usleep  (100) ; 

} 
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List  of  Symbols,  Abbreviations,  and  Acronyms 


AFRL 

Air  Force  Research  Laboratory 

COTS 

Commercial-Off-The-Shelf 

dBi 

decibel  isotropic 

dc 

direct  current 

FFS 

Feige-Fiat-Shamir 

GMP 

GNU  Multiple  Precision 

MANET 

Mobile  Ad  Hoc  Network 

MHz 

Mega-Hertz 

RF 

Radio  Frequency 

TCP/IP 

Transmission  Control  Protocol/Internet  Protocol 

UAV 

Unmanned  Aerial  Vehicle 

WEP 

Wired  Equivalent  Privacy 

WPA 

Wi-Fi  Protected  Access 

WPA  PSK 

Wi-Fi  Protected  Access  Pre-Shared  Key 

ZKP 

Zero  Knowledge  Proof 
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